user-menu: Be more cautious about saving status

When requesting a presence change, the actual presence set by
mission control does not necessarily match the requested presence
(if an active account does not support the requested presence),
which may result in the wrong presence being restored.
As a fix, be more cautious about saving status by assuming that
users do not request presence changes between an automatic presence
change request and the actual change.

https://bugzilla.gnome.org/show_bug.cgi?id=661485

diff --git a/js/ui/userMenu.js b/js/ui/userMenu.js
index 40ca2f39e56b19e32b9fa3de6b696a1f8664a390..311ba73e69b86c63ce2308dbd606393e6cfdf781 100644 (file)
--- a/js/ui/userMenu.js
+++ b/js/ui/userMenu.js
@@ -285,7 +285,12 @@ IMStatusChooserItem.prototype = {
         if (presence == Tp.ConnectionPresenceType.AVAILABLE)
             this._presence.setStatus(GnomeSession.PresenceStatus.AVAILABLE);
 
-        if (!this._expectedPresence || presence != this._expectedPresence)
+        // We ignore the actual value of _expectedPresence and never safe
+        // the first presence change after an "automatic" change, assuming
+        // that it is the response to our request; this is to account for
+        // mission control falling back to "similar" presences if an account
+        // type does not implement the requested presence.
+        if (!this._expectedPresence)
             global.settings.set_int('saved-im-presence', presence);
         else
             this._expectedPresence = undefined;